Major I.L. Holdridge is the author of TacOps (reviewed in this issue). IMG hunted him down for this exclusive interview.
IMG: You have a very strong wargaming background. Tell us what board games you are currently playing and what influenced you in selecting these games: specifically what are their strong points which attract you?
Holdridge: Well, unfortunately I can’t say that I am playing any board games right now because of the time that I am putting into playing and supporting TacOps. However, I have a stack of favorite board games nearby that I have played recently and that I expect to play again as soon as I can. In that pile are “Sands of War,” “Battlefield Europe,” “Team Yankee,” and “Phase Line Smash” — all by Frank Chadwick of GDW. In with them is GMT’s “Crisis: Korea 1995” by Gene Billingsley. I prefer these games because they feature relatively limited rules sets, are very playable, and yet are still able to produce battle results that feel right over the course of several turns.
IMG: What is your impression of current Macintosh wargames? Are there any that stand out from the rest of the field, and if so why?
Holdridge: Seems like Mac wargames just keep getting better and better. There has been a real quality explosion in the last two or three years. My tastes run to modern wargaming — World War II through the near future — so the current Mac game that stands out for me is Keith Zabalaoui’s “Crusader” (Atomic Games/Avalon Hill). I have only played a bit with the demo, but it seems to be a great game — it is artistically a beautiful piece of work and it looks to be very playable and highly accurate.
IMG: How do you see the PowerPC systems impacting the Mac wargaming community? So far it seems that few programmers have attempted to take advantage of the power of these systems. Knowing your philosophy of programming for last year’s system as opposed to next year’s, when do you see transitioning to the PowerPC system and what would it allow you to do?
Holdridge: Anything that increases the processing speed, memory, and hard disk space available to the average gamer has the potential for improving the detail, realism, and overall appearance of new wargames. If everyone had a PowerPC, I could probably provide a terrain and line of sight model that was mathematically accurate down to one pixel. In other words, the TacOps battle map could be a real military map with dozens of elevations or perhaps even an aerial photograph.
However, I don’t expect to baseline the performance of my games to the speed and power of native PowerPC code for at least two years. That could change though. So far I have not received much positive feedback for my attempt with TacOps to provide a new product that gives adequate to good performance on three and four-year old Macs. Maybe I have misappreciated the number of gamers using older machines. It is also possible that the average Mac gamer, understandably, does not appreciate the work and expense now required for a coder to maintain backward compatibility.
From the user’s perspective the Mac hasn’t really changed all that much in ten years. Sure it’s faster, has more memory, and offers color, but otherwise a Mac still appears to be a Mac. Coders know a far different reality. The backward compatibility challenge has worsened for them greatly in the last two years and it appears that things are going to get even stickier very soon.
In a niche market like wargaming, it is very risky to switch early to a new standard in either code or platform. Writing, testing, and debugging two or three versions of a program at the same time has to be slower and more complex than concentrating on one unless several teams can be used. Currently wargames are developed by very small teams. I don’t think there is enough profit in the wargame market to allow multiple team development on one wargame title. I would really be surprised if anyone could afford to use more than three people (a designer, an artist, and a coder) full time on a serious wargame.
Enough whining <grin>. The good news is that as the PowerPC customer base grows and as stable full featured development systems become available we should start to see wargames offered in PowerPC native code. Once that happens, then just about anything ought to be possible.
IMG: In your “biography,” you provide a good overview of your military career. Give us a story or example which directly impacted your design philosophy or the “realism” of TacOps.
Holdridge: I think TacOps reflects a general sense that I have that modern weapons are terribly efficient if they are in the hands of trained people who are willing to stand and fight. TacOps also reflects my belief that once a tactical-level battle starts, no one can maintain a certain picture of what is going on to their direct front, let alone on what is happening on the other side of the hill. Its hard to pin those beliefs to any one event or period in my military career. TacOps is a summation of all the observations I made during years of reading and study, a lot of listening to people who have been in combat, and from personal service in one position or another from a private’s rifle pit up to being a “horse holder” in the G-2 section of a Marine Corps Force Headquarters.
IMG: TacOps strives to simulate the weapons parameters and the effect of the environment in which they operate with maximum fidelity. I would be interested in your comments concerning two areas where I think the game’s fidelity may not be quite so true.
First let me tackle the subject of tactical battlefield communication: the game does not seem to account for the electronic warfare component of the engagement (i.e. manportable or helicopter jammers) nor does it impose the constraint of the speed of modern mechanized combat (i.e. limiting the number of orders the player may give in a turn, or preferably giving the player a real-time environment once the battle is joined).
Obviously, my comments are based on the perspective that the player is in fact the senior commander for the engagement and is actually somewhere on the “battlefield.”
Holdridge: Good point. TacOps does not specifically reflect the presence on the battlefield of effective electronic warfare — jamming and the like. Neither does it currently reflect wind, rain, snow, fog, darkness, A10s standing off while firing Maverick missiles, laser target designators, nuclear weapons, chemical or biological weapons, pistols, hand grenades, or what units in the game recently had a hot breakfast <grin>.
The list of details that might be present that could be significant to the outcome of a tactical battle is practically limitless. Unfortunately, the development time available to program, test, and fine-tune a $49 wargame, and the computer speed and memory available to the “average gamer” to play that game are not limitless. Compromises must be made, some details must be left out.
I would like to point out the TacOps program is currently being actively maintained and supported. That means that the game remains open not just for bug fixes but also for enhancement. The master code is still on my primary development system, and it will stay there as long as new sales and or current customer interest justify it. If people suggest changes and or additional details that they would like to see added to TacOps, I’ll consider their comments and I’ll put out some updates. I personally hang out in the Mac game areas of America Online and CompuServe and I monitor Internet Mac game traffic. Arsenal Publishing will also forward any US Mail received on TacOps to me.
I should mention that users who send me detailed, credible justification are more likely to see their suggestion implemented than are those that only post one sentence complaints.
On limiting the number of orders the player may give in a turn — this is an excellent example of game design decisions that I think a developer should leave to the game user. If a player thinks that TacOps would be more realistic if the number of orders that could be given were limited, then that player is currently free to stop giving orders at any point in the orders phase. If I hard-coded this into the game, the person who paid his good money for TacOps would be stuck with whatever I thought was correct. I don’t feel that I should unnecessarily limit what game owners do while playing TacOps. Players deserve the flexibility, wherever it is reasonable, to do things their way.
The same flexible approach covers real time play. I don’t think that most mature wargamers want the stress of playing a real time game. They want to reflect on the situation and plan a good response. They enjoy fiddling with the unit orders at their own speed. Since that is how I think most people want to play, that is the game default. However, if a person does want to play in real time then they can enable a optional turn timer in TacOps. They can choose the number of seconds or minutes to be allowed for giving orders that suits them . Once that time has elapsed during an orders phase, the program will automatically start the next combat phase.
IMG: Continuing the line of thought from the above question, I would ask your views on the lack of a morale “factor” in the game. I am in part aware of your views, but I would like to ask for a more detailed view. It was my impression at times, that the “human element” was missing from the simulation: the commander was located in a nice air conditioned office and the machinery was operated by some remote control method.
I am not ignoring the inclusion of “suppression” in the game. It just seemed that the program continued attacks, as well as defenses, with hopeless odds, and at times I had to question the ability of a conscript army (typically found in the OPFOR) to hold together in such a situation.
Holdridge: OPFOR as portrayed in TacOps is well-equipped, well-trained, and well-motivated. Even so, human players (US or OPFOR) are free to break contact whenever they like. If suicide attacks offend their sensibilities they may currently choose to not make them — the game engine does not force them to. When under the control of the computer opponent (AI), OPFOR units will continue fighting against hopeless odds. That is the nature of the TacOps AI opponent. That opposing forces might do this in the real world is a worst case possibility that US field commanders must consider.
Some of our past adversaries have not followed a set morale norm, perhaps some future enemy also won’t cooperate with our analysts and quit fighting after 30 or 50 or 90 percent casualties. Beyond the OPFOR considerations, I am very uncomfortable with hard coding breaking points for modern US military units. As a retired Marine, I am philosophically unable to specify a definable point in combat beyond which today’s average US soldier or Marine will not do his duty.
I am willing to concede that it is largely historically atypical, for all sides to fight battles of annihilation. I could easily say that the current high loss level in TacOps includes the folks who have simply chosen to permanently remove themselves from harm’s way. A better answer is that I think that morale must be approached very cautiously.
I believe that hard coding morale into the game would make everyone unhappy. The casual gamers would be displeased when units did not perform as ordered and serious gamers — a cantankerous group at the best of times — would quibble endlessly with whatever I implemented. Right now, I am leaning toward adding one or more morale factors as user selectable options and allowing the user to specify the numbers associated with triggering those factors.
However, whatever I do will be based primarily on customer input. I remain open to well-stated recommendations from TacOps owners on exactly how they would like to see morale implemented. Morale has to be optional though, I’m not open to forcing it on everyone. I have sent personal messages to a number of people who recently publicly complained about this, asking what would suit them — I have yet to receive a reply that contained much more than: “Gee I don’t know, but its gotta be in there — let me get back to you on that.” <grin>
IMG: Admittedly, with a controversial subject like morale, no matter what you implement, some will remain unhappy. As you mentioned, the hardest part is the actual definition of a set of rules governing morale. What besides past historical experience would you consider if you introduce this as an option?
Holdridge: I am keeping an open mind on the subject while awaiting user input. Still, it would seem that historical experience must be the primary consideration from the perspective of doing a simulation.
From the perspective of doing a game, there may have to be some compromises or tradeoffs made for playability and the need to provide gamers with some semblance of a “fair fight.” The most difficult problem in developing a wargame has always been the tension that exists between simulation gaming and popular entertainment gaming. I think that commercial wargaming has three audiences — those that expect a pure simulation, those that expect a good even game, and those that expect both.
The first two groups are relatively easy to satisfy but it usually takes two different products to do it. It is extremely difficult to satisfy the “I want it all” group, especially if one is dealing with historical battles. I would prefer to code for the simulation purists, but it is unfortunate but true that servicing only their tastes would not reimburse the cost of development. Although I enjoy pure entertainment games, I don’t personally care to code just for that group either. So, I will try to continue to address all three audiences by building in game and scenario options that allow the user to choose to play at a near simulation level or at a game level.
IMG: The database for TacOps is quite extensive. Did any of the weapon systems prove difficult to research or to model?
Holdridge: Yes, almost every single one of them. The small arms (rifles, machine guns, light antitank weapons, mortars) weren’t too bad because I had personally fired or observed the firing of many of them or their recent predecessors. Everything else was very tough.
There are a lot of good general references available for modern US and OPFOR heavy weapons but they do not provide enough detail to code to. When one is trying to define exact details like useful range, accuracy over range, and target effect (usually armor penetration) over range, one has to build on clues and fragments of often conflicting information from many different sources.
Let me give you one example of what is required. Say I want to simulate the depleted uranium penetrator ammunition — the “Silver Bullet” — of the M1A2 tank. Folks who are “in the know” are not exactly lining up to help me with this <grin>. I start with a stack of publicly available reference books and I begin looking for clues to its size, weight, range, muzzle velocity and the like. I then scan magazine articles and books for battle narratives and quotes from soldiers on tank kills during Desert Storm — more clues.
Someone brags in a popular magazine about one round from an M1 tank passing through two side by side T72 tanks and then I find the same incident mentioned in a public government report to Congress — getting close now. I turn off down a side road of doing the same kind of research for the armor on T72 tanks that were present in Desert Storm — got it — the Silver Bullet is mine and into the code it goes. Great, only 70 more weapons and 70 more units to go.
IMG: The majority of OPFOR weapons systems included in the game served in Afghanistan. Were you able to get to any pertinent information from this conflict and did you use it in the modeling of OPFOR systems in TacOps?
Holdridge: Yes, some, however since Soviet troops and first line equipment were withdrawn from Afghanistan in 1989, that war is getting a bit dated as a reference for a contemporary or near-future game. Technically many of the OPFOR weapons in TacOps are gamed as advancements on the Soviet equipment used in Afghanistan, but again books and articles on Afghanistan were very helpful and I did use much of that information in TacOps. David Isby in particular has published excellent materials on the Afghanistan conflict.
IMG: Some players may argue that the OPFOR database should include other nations’ equipment. In some regions of the world, the Middle East and Eastern Europe for example, it is very likely that former Warsaw Pact equipment and western military hardware will co-exist in the same nation’s TO&E for some years to come. Are you planning on modifying the OPFOR database to reflect these changes?
Holdridge: Those same players would probably also argue that I should provide an encyclopedic companion data base on a CD for $9.95 <grin>. However, yes, now that the basic game engine is done, I can put more time into expanding the number of units, vehicles, and weapons that are in the game.
I expect, major TacOps updates every year or so that will include these items. Minor updates should come out several times a year, but these will mainly cover easy-to-do US and OPFOR unit and weapon changes/additions, low-risk user interface enhancements, and the occasional odd bug fix. Minor updates will most likely continue to be free, though at some point there might have to be a slight charge for shipping and handling.
Bug fixes should always be free, and I am sure they will remain so especially for users with access to local BBSs, America Online, and or CompuServe (except for downloading time charges which I have no control over and from which neither Arsenal nor I will get a penny). We will probably have to extract some form of tribute for major updates that provide significantly increased product value, but I don’t expect extortionary charges.
IMG: I recently had the fortunate experience of observing a former Warsaw Pact nation’s military exercise. Undoubtedly, there have been some reforms introduced in the military since the changeover, but I still saw many of the characteristics of the traditional Soviet mass attack/prepared linear defense. To what extent did you take into account rigid “Soviet style” military planning (i.e. scripting the attack to the second, inflexible time-tables, etc.) when you designed the AI?
Holdridge: A lot. The majority of the OPFOR AI battle plans (i.e. its opening moves and its overall strategy in a given scenario) and the AI’s usual response to contact reflect conventional wisdom on the “Soviet style.” By the way, most of the scenarios have from three, four, or five to several dozen different OPFOR AI battle plans — the larger scenarios that have OPFOR in the attack usually approach the larger number. Which one the US player ends up having to deal with in each scenario replay is a random event. Some of these plans are less rigid than the Soviet model. Some are more rigid. A few are quite stupid — same as in real life. The TacOps user who only plays a particular scenario once or twice is missing a lot of entertainment value.
IMG: You had mentioned that in some cases players had convinced you of implementing changes in TacOps based a well-supported argument. Can you give us some examples of this? What influences you most in a player request?
Holdridge: What influences me most for weapon and unit changes is a well-reasoned argument supported by evidence — either “I saw it happen in the field” or a credible documentary reference (simply citing other wargames does not help). For user interface changes, a good stepwise explanation of how a player would rather see something handled works best. I collect all complaints though, even the short, non-helpful ones. If I hear the same thing, especially in user interface items, several times from experienced players then I figure I must be wrong and I’ll start pondering a different approach.
The TacOps play testers were not mere bug hunters. We tested for a long time. The early participants went through a dozen or more beta versions. Technically, the early testers were not really beta testers at all. They were closer to a design focus group, although we never mentioned it.
The very best changes during development came from the play testers and it frankly flabbergasted several to see their non-bug related comments actually implemented within a few days of their being suggested.
Examples? My development log shows over a hundred. TacOps started out as a Marine Corps-only game. For obvious reasons I was satisfied with that and, oddly, so was Arsenal. Adding US Army units and equipment was scheduled for a future major update. Most of the playtesters (especially the former Army gents <grin>) rebelled and several immediately sent me a pot full of useful Army info. The program was delayed at least two months just to add US Army units and weapons.
The play testers wanted access to more information on units and weapons. They specifically asked for more text on this in the manual. I said OK, but lets be more creative than that, so I added the online photo, unit, and weapon databases providing one click access to the most game-relevant information.
There was constant sniping from the simulation fans and the “let me play it my way” guys so I implemented many controversial items two ways as user-selectable options. I added the setting of target priorities by unit, by target class, and by Target Reference Point to satisfy several active duty gents who wanted to plan, think, and use the same terms in the game that they did in the field. The ability to give units orders to move backwards, eight new SOP orders options for more control over their units, displaying movement waypoints and waypoint time hacks, ammo reports, scenario editing, custom scenario templates, option for more random spotting, surprise fire, entrenchments, I could go on and on.
IMG: Did you implement any modifications to TacOps, based on player suggestions, that you yourself may not have agreed with, in principle at least?
Holdridge: I did not agree with reducing the ability to spot firing units. I felt I had already addressed this in the weapon accuracy tables. Though more realistic, I thought most game players would be annoyed at receiving fire from enemy units that often remained invisible and thus impervious to return fire. I thought they would perceive this as too much fog of war.
I added it as an option, and have since found that experienced players soon switch to it. Heck, even I prefer it now. I resisted letting the players give more detailed orders to their units, especially the expanding of what were initially only a couple of SOP reaction orders. I did not want TacOps turning into a programmed robot game. After a while I gave in, added eight more SOP choices and some other new buttons, and was quickly forced to admit that it made the game more realistic and that it made the orders phase more interesting and not more complicated. As a by-product, this gave me some routines that almost instantly improved the AI play. There are others, but I don’t want to eat too much crow at one sitting <grin>.
IMG: What does the future hold for TacOps? Are there any “expansions” planned?
Holdridge: Assuming I don’t have to get a “day job” <grin> and in no particular order — user suggested interface enhancements, more maps and scenarios, more units, more weapons, more nationalities, more elevations and altitudes, A10s, a more detailed air to ground model, infantry and vehicle-mounted laser designators so the Apache helos can realize the full range potential of their Hellfire missiles, increased fidelity in the terrain data base, greater scenario editing, a US computer opponent, optional morale (ugh), 256 colors, etc. — the official update and upgrade lists are lengthy.
Not everything on these lists will be done in the next 12 months — some require a lot of research, some will require lengthy testing because they involve major code changes, and some are dependent on the “average gamer” evolving to a LCIII or a low-end Quadra capability.
Development is also currently well along on a TacOps spin-off series, TacOps: WWII. TacOps: WWII will not be a TacOps update or upgrade. The differences between a World War II game and a contemporary game are too great to be adequately addressed in one game engine. We are trying to maintain the same look and feel though. I say “we” here because TacOps: WWII has a three member development team — the first TacOps was done just by me (and of course the playtesters).
IMG: What was the primary reason for the expansion of the development team for the WWII TacOps?
Holdridge: Actually there were four primary reasons — ensuring historical accuracy, increased artistic demands, reduction of development time, and lastly the fact that I just don’t have the time to do everything anymore. I very much want to code (and play <grin>) a good tactical level WWII game, but I don’t have the professional experience in WWII subjects that I have in contemporary military matters, nor do I have an adequate WWII library.
Ed Rains is an absolute expert on the WWII period and the depth of his personal WWII library is amazing. We were already working together on D-Day so the right thing to do was to make him pretty much singly responsible for laying out the WWII weapons, organizations, scenarios, and tactical concepts that will be in TacOps: WWII. When we made the decision to dump System 6 for the WWII game that made it more reasonable to move to 256 colors and to increase the detail to be shown on the unit markers and the map. Greater graphic detail called for a much better artist than myself, so a real art person was added to the team.
Third reason — three people, who get along well, can get a game done faster than one. Lastly, as I must continue to put a fair amount of time into supporting and enhancing TacOps there wasn’t enough of me to go around to do the WWII game by myself.
IMG: In all fairness, I should not focus solely on the products. What then does the future hold for you? Is a well deserved vacation in the works?
Holdridge: Vacation? What is that? Frankly, I don’t know what the future holds for me — the decision is up to your readers. They are currently voting with their hard-earned dollars. If TacOps does well then I’ll be able to continue doing what I enjoy most — coding and playing wargames. If not . . . I guess I’ll get a haircut, buy a tie, and start practicing the phrase “would you like fries with that.”
IMG: If there is anything you’d like to say in your or your game’s defense <grin>, and I have not prompted you yet, please feel free to do so now.
Holdridge: Actually there is. I don’t want my comments to be taken as exaggerating the simulation accuracy of TacOps or as inflating my analysis capabilities. I think TacOps is very good at reproducing the tactical concepts of contemporary and near-future combat operations but it is not a multi-million dollar, government-supported, super-detailed military training aid and I am in no way suggesting that it is. I also do not intend to represent myself to be a perfect expert on all things military.
I think it is reasonable to assume that there are errors of detail in the game’s unit and weapons data bases, however I don’t think there are likely to be very many inaccuracies that are game-significant. Still, I repeat my standing invitation to any knowledgeable user to send me credible contemporary evidence to support changes and or error correction. Send me the proof and I will make the changes. TacOps is a supported program.
